Sesión 6

Fecha: 21/03/2025

Hora inicio: 10:40

Hora finalización: 14:30

Lugar: Aula H1.12

Grupo 2

GastroStock

Ayuda a la gestión de inventarios de bares y mejora de logística mediante IA.

Feedback positivo de estudiante

• Killer opener que relaciona el problema con una solución
• Expone muy calmado, quizás demasiado. Falta emoción.
• Da información precisa sobre el costo de una TPV, lo cual no es de conocimiento común y aporta al contexto.
• Crea un personaje “tio gilito” que retoma un poco la atención.
• Los tiempos de la demo están más o menos bien cuadrados.
• El chascarrillo sobre el nuevo integrante del grupo ha sentado bien.
• Usa un lenguaje con impacto “las cabras del equipo”. En este entorno funciona.
• Robo de de portátil a un compañero se toma como riesgo y se evalua.
• Buena idea usar el ratón como pasante.

Feedback negativo de estudiante

• Killer opener muy largo, comparado con otros grupos no tiene el mismo impacto.
• Es un poco monótono en el discurso, lo que provoca una pérdida de interés en el público.
• Pasan muy rápido los competidores, dice que lo hace porque ya los conocemos, entonces por qué poner 3 diapositivas dedicadas a ellos.
• El video de la demo no está muy preparado.

Feedback de profesores (Pablo)

• No se aporta información cuantitativa de nada. No se apoya en nada.
• A partir de ahora lo normal es que un público común no entienda la parte más técnica de la presentación. Al no existir elementos cuantitativos, ha generado suspicacia, informalidad e inseguridad. Se piden datos como porcentajes de mejora, rendimiento….
• Cuando se introduzca un dato cuantitativo, se debe introducir un contexto, si un inversor llega a ver si hay potencial y retorno de inversión, en la presentación dice que “obtendrán un x% del mercado”, el inversor no va a sacar una calculadora y a ponerse a hacer cálculos, se le deben entregar los números que permitan al oyente analizar si tus argumentos son o no creibles. (no un %, sino miles de euros por ejemplo, o no un % del mercado sino introducción en 500 locales)
• La penetración de mercado se puede hacer como un estimado, si nos equivocamos pues bueno, pero está bien que se estime. (una estimación en dinero es mucho mas dificil que una en clientes, pues este primero es una consecuencia lógica del segundo)

Feedback de profesores (Cristina)

• Inicio efectivo bueno, pero muy largo. Dice detalles menos relevantes. Debe acortarse. Está bien alineado con la presentación.
• Muy monótono. He empezado con energía, pero he bajado el nivel.
• En los costes, la elección de colores debe ser intuitiva, lo bueno debe ir en verde y lo malo en rojo por ejemplo.
• Demo muy mejorable, mucho “también puede ver”, hay que amenizar. Faltan personajes y guión, contar una historia.
• Los anuncios no se ven bien. Replantearía muchas partes de la presentación.
• Faltan problemas, riesgos, storyboard…

Grupo 3

EVENTBRIDE

Aplicación para gestionar eventos cristianos; bodas, bautizos y comuniones

Feedback positivo de estudiante

• Muy buen killer opener que hila con la historia de la semana pasada y con el propósito de la app.
• Miguel es un icono de la efusividad, lo cual hace que el killer opener sea más cómico.
• Mucho entusiasmo y energía en la presentación.
• Hablan sobre el seguimiento de un código de conducta, lo cual es muy interesante.
• Muy interesante las menciones especiales.. Han hecho caso al feedback.
• Tienen desarrolladas cuentas de instagram y tik tok.
• Muy buen storyboard.
• Han definido un público objetivo para el storyBoard.
• Muy buena demo. Se escucha muy bien, hay zooms y tiene muy buen guión.
• Buena autocrítica.
• Muy buena presentación en el rendimiento.
• Son sinceros con los problemas.
• Buena velocidad mental para responder a las preguntas de los alumnos.

Feedback negativo de estudiante

• Sigue hablando muy rápido.
• La fórmula se ve muy mal, podrían introducirla en latex.

Feedback de profesores (Carlos)

• Cree urgente que obtengan un pasante (para no tener que ir mirando al que pasa las diapositivas).
• Muy bien enlazado el killer opener con el problema que solucionan.
• El storyboard lo ve MUY BIEN. Le ha gustado el detalle de dibujarlo a mano.
• En el anuncio, centrarse en bodas no es buena idea, porque das a entender que es lo único que haces.
• Falta la viñeta final de pricing.
• Diagrama de barras para ver la diferencia entre costes y ganancias.
• Hay que destacar más la línea de costes. Se queda perdida.
• Muy buenas las fórmulas, dan bastante detalle, pero falta algo más, quizás una pequeña gráfica para el rendimiento entre sprints (si va en aumento o decremento).
• Marvilla de demo, le ha encantado. Imposible no estar atento a la demo. Lo único es cuando la octogenaria dice que es muy complicado y después que es una maravilla.
• Falta gráfica para ver cómo evoluciona la calidad del código.
• Lo bueno se copia
• Hay que ser capaces de medir las soluciones.

Feedback de profesores (Cristina)

• No hacer referencias a las semanas anteriores.
• Cuesta seguir los números muchas veces, pues la única referencia que se da es: “Como se puede ver aquí”
• En la trasparencia 8, la línea de corte ha de estar más destacada
• En cuanto al equipo, le queda la duda si tienen un GDPR manager.
• Diapositiva 27, se habla de problemas y luego de problemas encontrados, preferiría todos los problemas en la misma transparencia.

Grupo 4

BORROO

Aplicación para generalizar el alquiler de objetos, es de matchmaking-improved market

Feedback positivo de estudiante

• Killer opener bueno, hila muy bien con su app
• Vuelve a hilar la presentación con el killer opener.
• El segundo storyboard que muestra es mejor que el primero. - Simple, pero muestra la funcionalidad.
• Don Ramón nos acompaña durante la presentación.
• No hay parte de la pantalla que se desperdicie, utilizan la completitud del espacio que tienen, dando una sencilla visión al público.
• Incluyen métodos cuantitativos para evaluar el rendimiento.
• Hace referencia a riesgos que se encontraron y sucedieron, y como la solución a estos ha resultado en una clara mejora en este sprint.
• Han mejorado mucho la forma de presentar, ha sido más calmado.

Feedback negativo de estudiante

• Es el mismo killer opener que en la última presentación, si bien funciona, quizás seria buena idea innovar.
• Mucho tiempo analizando competidores, no es necesario.
• Storyboard muy escueto, solo dos imágenes y sin mucho sentido. El segundo anuncio mejora.
• El video demo no está mal, pero no tiene voz ni guion ni personajes.
• Las imágenes en usuarios piloto no tienen ningún tipo de relación con lo que se está hablando.
• Presentación muy larga.

Feedback de profesores (Pablo)

• No usa K, usan mil y recomienda poner K.
• Insiste en que en la gráfica de revisiones de estimaciones (10), se debería entender la diapositiva en términos de qué significa, lo de k € viene recogido en la RAE y debe ser lo utilizado en su opinión. Si lo que hay que analizar en la gráfica es si es realista, hay que entender de donde salen los números, y para entenderlo bien hay que entender la atracción estimada (volumen de transacciones, clientes atraídos), para yo estimar cómo de realista es, deberíamos estimar cuántas transacciones se realizarán.
• Desde el sprint 1 debe haber feedback de los usuarios piloto y que la usen, por ahora no han podido usarla los usuarios pilotos, a día de hoy si no se ha podido usar todavía, vamos fatal. Estamos en peligro.
• Las transparencias genéricas no son buena idea, si en una transparencia no hay algo específico del proyecto, hay que repensar si es necesario ponerlo, pues si es algo común a todos los proyectos, nohace falta ponerlo.
• Lo de la solicitud de alquiler le ha sorprendido, pues era su valor diferencial y lo han dejado para el Sprint 2, todos los esfuerzos han de ir dirigidos al valor diferencial en contra de la competencia.

Feedback de profesores (Cristina)

• En la transparencia número 4, el storyBoard le ha parecido poco ocurrente y bastante simple, con la imagen no se describe la historia que proclaman sigue.
• No intenta convencer a ningún inversor, tienen que decir, cuánto tienen que abonar y cuánto ganarán.
• En la traspa 23 (rendimiento del equipo), cuando dicen que todos han sacado un 10, ¿han cumplido todos con todo?
• En la 38 (IA), la diapo es muy genérica, se habla mucho pero hay poco, se podria decir que herramientas IA se han usado, como, debe ser más completa la traspa.
• Trampas sin título han sido corregidas, aquí han seguido el feedback

Grupo 5

Camyo

App para juntar camioneros con empresas

Feedback positivo de estudiantes

• Buen killer opener
• Presentación muy visual
• Muy buena la traspa de los costes.
• Muy buena cantidad de diapositivas.
• Muy buenos datos de usuarios piloto.
• Comenta peticiones de los UP, muy interesante
• Demo completa, se muestra la funcionalidad completa.
• Han resuelto bien sus problemas de carga de trabajo de backend y frontend.
• Han tomado medidas para la planificación del proyecto creando todas las issues en el primer día.
• Han hecho caso al feedback y han añadido los empleados de la semana.
• Termina con el QR de la landing page.

Feedback negativo de estudiante

• Presentador nervioso. Da paseillos.
• La demo no se ve bien y tampoco se escucha muy bien.
• Es importante vocalizar en la demo, no se entiende.
• Muy larga la demo.

Feedback de profesores (Carlos)

• He empezado más nervioso de la cuenta por el problema técnico, hay que empezar como si nada hubiera pasado.
• El storyBoard necesita un usuario target definido, sino no funciona, si quieres centrarte en un público objetivo tienes que dedicarle a ellos el storyBoard.
• El killer opener le ha gustado, aprovechar elementos del momento siempre está muy bien, pero le sigue faltando una mejor conexión con la demo.
• Capex y opex bien interpretados
• Tienen separado costes y ganancias y no le permite unirlo todo. Una gráfica de corte puede quedar bien (Gastos/Ingresos).
• Ha dicho muchas cosas sin apoyo visual, esto puede hacer que los oyentes desconecten.
• La demo se escucha y se ve poco.
• El audio lo ha grabado una sola persona y deberían ser dos.
• En la traspa 19 (reloj de avance del proyecto) hay demasiada incertidumbre.

Feedback de profesores (Cristina)

• Inicia muy bien la presentación.
• Un poco rápido, la primera parte se la han perdido, tras los competidores, lo que hace la app en el storyboard no se ha entendido
• ¿A quién va dirigido el storyBoard? Quizás haya que hacer un storyBoard por cada usuario target.
• Le gusta el enfoque del ámbito legal, las conclusiones y decisiones le gustan.
• Cuidado con la expresión. «Bueno, ¿Cuánto costamos?», hay que intentar matizar bien los términos que se usan. También usa «Competición» en lugar de competidores. Hay que corregirlo.
• No le ha quedado claro si han clasificado o no el feedback de los UP, es importante clasificarlos por importancia para el sprint 3.
• La demo no se ve bien, no se escucha bien, y se hace monótona.
• Le falta el email de contacto en la última transparencia.
• No han tenido ningún problema en la retrospectiva, esto le resulta raro.

Grupo 6

FisioFind

App para consultas de fisioterapia

Feedback positivo de estudiante

• Killer opener muy bueno. Una historia que une con el problema.
• Ataca a la sanidad pública.
• Buena idea cambiar los presentadores en una semana intermedia.
• El presentador se nota preparado.
• Hace referencia a las Theory Pills, para marcar su seguimiento.
• Buen cambio en el CA, al cambiar la penalización por un sistema de recompensas.
• Introduce los 3 mejores miembros del equipo en la semana.
• Utilizan lo que funciona en otros grupos y lo toman como suyo.
• La presentación se ve muy bien. Mantiene un diseño homogéneo muy bueno. Muy visual.
• Son conscientes de que una solución dada a un problema del sprint anterior se ha convertido en un problema (Foro de FAQ).
• Muy buena idea el meme de la semana.
• Costes claros.
• Hace buenos chascarrillos durante la presentación para retomar la atención de la audiencia.
• Termina con toda la información y del QR.

Feedback negativo de estudiante

• Tiene una dicción demasiado rápida a veces. Pero no parece nervioso.
• Se para mucho en los competidores.
• Añaden una métrica y luego le restan valor diciendo que no es representativa del estado actual del proyecto.
• Demo muy rápida, sin zooms y sin voz ni, evidentemente guion. Muy por detrás del resto de la clase. Es importante copiar lo bueno.
• La demo no da tiempo a ver bien, va muy rápido, hay pantallas donde la letra es muy pequeña.
• La demo va tan rápida que se ha perdido con la presentación. Storyboard muy breve. Y en un estado precario.

Feedback de profesores (Carlos)

• A Dani le ha faltado un poco de energía al presentar.
• Lo que le faltaba al supermega anuncio de Guadalupe era lo que hoy ha comentado Miguel.
• La mezcla sería estupendisima y divina de la muerte
• Hay que pensar formas más efectivas de hacer graficas. Como gráficas acumulativas para ver todas las tasks que están en to do, in progres…
• Los carteles que explican la funcionalidad pasan muy rápido. Podrían ponerme más tiempo o ponerlo a un lado.
• Ya están contemplando el tema de aspectos legales, esto le gusta mucho.
• Deberían copiar algunas métricas que funcionan en otros grupos o dar un mayor nivel de detalle en las suyas propias.
• El sistema de recompensas debería ser gratuito. (Dejar que él elija primero la issue que quiera hacer)
• En las transparencias 19 y 20. Falta evolución de los problemas encontrados. Falta ver si la solución es eficiente,
• Cambiar los colores de abierto y cerrado. Sale abierto en verde y cerrado en rojo.
• Medir cuán alcanzable es el objetivo hasta la fecha.

Feedback de profesores (Cristina)

• Buen inicio efectivo, deja bien claro lo que no existe para que en el elevator pitch se destaque lo positivo. Bien ensayado el discurso.
• Ha mejorado mucho la apariencia visual. Le gusta mucho, es muy profesional.
• Han dedicado mucho tiempo en los competidores.
• Buen guiño a la píldora teórica.
• Mucho implementado
• La demo no se ve bien, es muy pequeña.
• Los jueves el aula está reservada, se lo recuerda al grupo por algo.
• Pregunta cómo se mide el rendimiento del equipo.
• Esperan ver todas las semanas el rendimiento.
• La métrica a veces es un objetivo y otra cosa es la evolución para llegar al objetivo, ponerlo en una misma columna de métrica no es adecuado.

Feedback general de final de clase

• Proximo dia evaluación, ver las píldoras teóricas.
• Sugiere no hablar mucho de las reuniones en las presentaciones. Sugiere también un calendario compartido para llevar a cabo las reuniones.
• Recomienda tener un changelog para tener un seguimiento.
• fix, docs, feats, son etiquetas que nos recomienda usar para mejorar el historial
• Pilot User Commitment Agreement con los estudiantes.
• Tener cuidado a la hora de salir y entrar.

Para el próximo día

• Introducción killer opener max 1 min
• Elevator pitch 30 seg
• Análisis de competidores al grano
• Storyboard de otro target (usuario, cliente, inversor)
• Customer agreement (clausular no abusivas a ser posible)
• Princing
• Acuerdo de nivel de servicios
• Implicaciones con apis a nivel de terceros que quiza debamos añadir, si tienen repercusión.
• SLAs
• Implicación en la implementación
• TCO igual que hasta ahora
• Resumen del equipo y roles.
• Commitment Agreement Status.
• Demo mejorar.
• retrospectiva sprint 2
• Añadir un gráfico (matriz de rendimiento y esfuerzo con 4 cuadrantes, arriba derecha alto rendimiento y esfuerzo, alto rend y poco esfuerzo, poco rend poco esf…)
• Resultado de análisis de software
• Problemas encontrados: Además del estado, decir explícitamente acciones concretas de cómo se ha abordado o se está abordando el problema y tenemos que evaluar de alguna forma estas soluciones. (ha servido la solución o no) y lecciones aprendidas
• Reloj del avance del proyecto con rendimineto y esfuerzo
• Gestión de usuario piloto, feedback recibido, comunicación con ellos…
• Planificación y replanificación (de cara al sprint 3)
• (S3) Aspectos de seguridad: Validar cuentas de correos, que las tarjetas de crédito tengan el numero de digitos… - Validez de datos, validez en los formularios.
• ¿Las api de comprobación tienen reflejos en el opex?
• Se puede hacer lo de enviar un correo y que se pulse un botón como verificación.
• Evitar cosas genéricas. No triviales.